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DETAILED ACTION 

1. This Office Action is in response to the communication filed on 08/12/2004. 
Claims 1-17, 19-35, 37-47 and 49-79 are presented for examination. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another 
filed in the United States before the invention by the applicant for patent or (2) a patent granted on an 
application for patent by another filed in the United States before the invention by the applicant for patent, 
except that an international application filed under the treaty defined in section 351(a) shall have the effects 
for purposes of this subsection of an application filed in the United States only if the international application 
designated the United States and was published under Article 21(2) of such treaty in the English language. 

3. Claims 1, 7, 19, 26, 37, 49-54, 64, and 71 are rejected under 35 U.S.C. 102(e) 
as being anticipated by Fuisz et al. (US 6,389,455), herein after referred as Fuisz. 

4. As per claim 1 , Fuisz teaches: 

generating a message envelope (by taking the advantage of the RFC 822, the 
822 message is wrapped in an "envelope" called a "data envelope" or a "message 
envelope" and transferred between servers) (Fuisz, C4: L65-67); and 

generating contents of the message envelope (i.e., generating a header and 
body of the message envelope), the contents comprising data structures, each data 
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structure identifies which entity is intended to process the data structure when that entity 
receives the message envelope over the network (i,e., header comprising data 
structures, e.g., header fields according to RFC 822 such as Trom", "Subject", 
"Sender", "To" - primary recipients, "cc" - secondary recipients , "Bcc" - blind carbon 
recipients, "Received", "Date", "Return-Path", "Options", etc., wherein optional-fields 
may be defined and used on Internet security, suggested routing path, previous routing 
path, time stamps, and among other things, updated by every Mail Transfer Agent 
"MTA" and bounce hub which is intended to identify the type of the message, to obtain 
any necessary forwarding information and to process the message accordingly as the 
message passes through) (Fuisz, C4: LI 9-31; C4:L65 - C5:L5, and C5: L29-34; RFC 
822, pages 17-18). 

5. Claims 19, 37, 49-54 and 64 claim similar limitations to that of claim 1 and are 
rejected on the same grounds as claim 1 and Fuisz further teaches: 

transmitting a message envelope of a message from an origin entity to a 
destination entity via one or more intermediate entities on the network (Fig. 1; col. 3, line 
55 - col. 4, line 5; col. 4, lines 19-31); 

parsing a message envelope and its contents (bounce hub extracts "to" and 
"from" information; col. 5, lines 19-28); and 

the message comprising at least one request by one entity on a network of 
another entity on the network to perform a task (inherent that the receiving computer is 
to handle the email in some fashion). 
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6. As per claim 7, Fuisz teaches the method of claim 1 and furthermore teaches 
sending the message envelope to an entity on a network (Fig. 1 , C3: L55-67). 

7. Claim 71 claims similar limitations to that of claim 7 and is rejected on the same 

s 

grounds as claim 7. 

8. As per claim 26, Fuisz teaches the method of claim 19 and further teaches at 
least one of the data structures including a request for an intermediate entity to perform 
a task (header is updated by every mail transfer agent and the bounce hub) (Fuisz, 
C4:L65-C5:L10and C5: L19-34), 

Claim Rejections - 35 USC § 103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject nnatter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time, the invention was made to 
a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

10. Claims 2, 20, 38, 55, 58, 61, and 65 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Fuisz, in view of Lefebvre et al. (US 2002/0010665 A1), 
herein after referred as Lefebvre. 
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11. As per claim 2, Fuisz teaches the method of claim 1 , but does not explicitly teach 
data structures specifying whether the entity intended to process the data structure 
must understand the data structure. 

In a related art, Lefebvre teaches data structures specifying whether the entity 
intended to process the data structure must understand such data structure (a DTD is 
used to specify the rules a document must conform to and is used in grammatically 
analyzing the document, a DTD is not required in all documents) (Lefebvre, paragraphs 
[0116-0121]). 

Therefore, it would have been obvious to one of ordinary skill in the art to modify 
the Fuisz invention to include specifying if an entity should understand a data stnjcture it 
is to process, as taught by Lefebvre, because for important messages communicated, 
specifying the need for understanding ensures the document is formatted with respect 
to the rules so that it is much less prone to having or causing errors, as taught by 
Lefebvre (page 10, paragraph 01 16). 

12. Claims 20, 38, and 65 claim similar limitations to that of claim 2 and are rejected 
on the same grounds as claim 2. 

1 3. As per claim 55, Fuisz teaches: 

providing a sending entity in communication with a network of entities (Fig. 1 ); 
generating contents of the message envelope (i.e., generating a header and 
body of the message envelope), the contents comprising data structures, each data 
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structure identifies which entity is intended to process the data structure when that entity 
receives the message envelope over the network (i.e., header comprising data 
structures, e.g., header fields according to RFC 822 such as "From", "Subject", 
"Sender", "To", "cc", "Bcc", "Received", "Date", "Return-Path", "Options", etc., wherein 
optional-fields may be defined and used on Internet security, suggested routing path, 
previous routing path, time stamps, and among other things, updated by every Mail 
Transfer Agent "MTA" and bounce hub that the message passes through) (Fuisz, C4: 
L19-31; C4:L65 - C5:L5, and C5: L29-34; RFC 822, pages 17-18). 

However, Fuisz does not explicitly teach data structures specifying whether the 
entity intended to process the data structure must understand the data structure. 

In a related art, Lefebvre teaches data structures specifying whether the entity 
intended to process the data structure must understand such data structure (a DTD is 
used to specify the rules a document must conform to and is used in grammatically 
analyzing the document, a DTD is not required in all documents) (Lefebvre, paragraphs 
[0116-0121]). 

Therefore, it would have been obvious to one of ordinary skill in the art to modify 
the Fuisz invention to include specifying if an entity should understand a data structure it 
is to process, as taught by Lefebvre, because for important messages communicated, 
specifying the need for understanding ensures the document is formatted with respect 
to the rules so that it is much less prone to having or causing errors, as taught by 
Lefebvre (page 10, paragraph 0116). 
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14. Claims 58 and 61 claim similar limitations to that of claim 55 and are rejected on 
the same grounds as claim 55. 

15. Claims 56-57, 59-60, and 62-63 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Fuisz, in view of Lefebvre, and further in view of IHemphill et al. 
(US 6,167,448), herein after referred as Hemphill. 

16. As per claims 56-57, Fuisz-Lefebvre teaches the method of claim 55, but does 
not explicitly teach the header or body data being expressed in XML. 

In a related art, Hemphill teaches that messages across a network can be 
formatted in a Markup Language, e.g., extensible Markup Language (XML, CI: L40-47). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to express the data structures in the modified Fuisz invention in 
XML, as taught by Hemphill, because XML provides a flexible and powerful method of 
notification of management events, as taught by Hemphill (XML, col. 1 , lines 48-52). 

17. Claims 59-60, and 62-63 claim similar limitations to that of claims 56-57 and are 
rejected on the same grounds as claims 56-57. 

18. Claims 4, 6, 8, 22, 24, 25, 42, 44, 45, 68, 70, ad 72 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Fuisz et al. (US 6,389,455). 
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19. As per claim 4, Fuisz discloses the claimed invention described above in claim 1 
and furthermore teaches a header data structure (col. lines 65-67); and a body data 
structure (col. lines 65-67). 

However, the Fuisz invention does not explicitly teach the body data structure 
including message data. "Official Notice" is taken that both the concept and advantages 
of having the body of a message contain message data are well known and expected in 
the art. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to have the message body in the Fuisz invention include message 
data because this would allow the sending entity to communicate actual data to the 
receiving entity, not just hollow data structures. 

20. Claims 22, 42, and 68 claim similar limitations to that of claim 4 and are rejected 
on the same grounds as claim 4. 

21. As per claim 6, Fuisz discloses the claimed invention modified above as 
described in claim 1 and furthermore teaches the header data structure being intended 
for at least one intermediate entity and the body data structure is intended for a 
destination entity (header and body structures, header is set off from the body, header 
is updated by Mail Transfer Agents and bounce hub only needs to work on header, 
body can be left for recipient; col. 4, lines 19-31; col. 4, line 65 - col. 5, line 5; col. 5, 
lines 29-34). 
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22. Claims 24, 44, and 70 claim similar limitations to that of claim 6 and are rejected 
on the same grounds as claim 6. 

23. As per claim 8, Fuisz discloses the claimed invention described above in claim 1. 
However, Fuisz does not explicitly teach the data structures including a request for an 
entity to periderm a task, wherein the data structures lack instructions for peri'orming the 
task. 

"Official Notice" is taken that both the concept and advantages of an email being 
sent from one computer to another computer for the purpose of the second computer 
displaying the email are well known and expected in the art. Therefore, the emails sent 
in Fuisz are requesting the second computer to perform a task of displaying the email. 
"Official Notice" is also taken that it is well known and expected in the art that email can 
contain no executable instructions that cause a computer to display the email, rather 
just the data to be displayed by the executable instructions on the second computer. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to have the data structures in the Fuisz invention request an entity 
to perform a task wherein the data structures contain no executable code because this 
would allow for users of email systems to have different email programs, each with their 
own executable code, and allow the email to contain only data needed by the 
executable code to perform the task of displaying the email. 
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24. Claims 25, 45, and 72 claim similar limitations to that of claim 8 and are rejected 
on the same grounds as claim 8. 

25. Claims 3, 5, 9-10, 14-17, 21, 23, 27-28, 32-35, 41, 43, 46-47, 67, 69, 73-74, and 
78-79 are rejected under 35 U.S.C. 103(a) as being unpatentable over Fuisz, in 
view of Connolly (Hypertext Markup Language - 2.0), and further in view of 
Hemphill. 

26. As per claim 17, Fuisz discloses the claimed modified invention described above 
in claim 4. However, Fuisz does not explicitly teach a message envelope format, 
envelope, header, or body tags, and expressing the data in XML. 

In a related art, Connolly teaches: 

a message envelope having the format of: 
<Envelope label> 

<Header label> 

header data 
</Header label> 
<Body label> 

message data 
</Body label> 
</Envelope label> (section 3.4); 
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the <Envelope label> being a beginning envelope tag, the </Envelope label> 
being an ending envelope tag, and the Envelope label identifying the message envelope 
{start-tags are delimited by '<' and ">', like <HTML>, and end-tags are delimited by '</" 
and '>', like </HTML>, wherein start and end tags identify the start and end of an 
element; page 7, 5'" definition; page 9, 2"^ definition; section 3.2.2, paragraph 1); 

the <Header label> being a beginning header tag, the </Header label> being an 
ending header tag, and the Header label identifying the header data structure (start-tags 
are delimited by '<' and '>', like <HEAD>, and end-tags are delimited by '</' and '>', like 
</HEAD>, wherein start and end tags identify the start and end of an element; page 7, 
5'" definition; page 9, 2"" definition; section 3.2.2, paragraph 1); and 

the <Body label> being a beginning body tag, the </Body label> being an ending 
body tag, and the Body label identifying the body data structure (start-tags are delimited 
by '<' and '>', like <BODY>, and end-tags are delimited by '</' and '>', like </BODY>. 
wherein start and end tags identify the start and end of an element; page 7, 5^ 
definition; page 9, definition; section 3.2.2, paragraph 1). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to include tags to define the beginning and end of a data structure, 
as taught by Connolly, in the Fuisz invention because tags delimit elements and allow 
for the definition of the content in an element, as taught by Connolly (section 3.2.2). 

However, the modified Fuisz invention does not explicitly teach the header or 
body data being expressed in XML. Hemphill teaches that messages across a network 
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can be formatted in a Markup Language, namely extensible Markup Language 
(Hemphill, XML, C1: L40-47). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to express the data structures in the modified Fuisz invention in 
XML, as taught by Hemphill, because XML provides a flexible and powerful method of 
notification of management events, as taught by Hemphill (col. 1 , lines 48-52). 

27. Claims 3, 5, 9-10, 14-16, 21, 23, 27-28, 32-35, 41, 43, 46-47, 67, 69, 73-74, and 
78-79 contains limitations that are either similar to, or contained within, claim 17 and are 
rejected on the same grounds as claim 17. 

28. Claims 11-13, 29-31, and 75-77 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Fuisz et al. (6,389,455) in view of Hemphill. 

29. As per claims 11-13, Fuisz discloses the claimed invention described above in 
claim 1 . However, Fuisz does not explicitly teach formatting the message envelope for 
HTTP transmission, binding the message envelope into a HTTP request or response, or 
sending the envelope via HTTP. Hemphill teaches: 

formatting a message envelope for sending over a network using HTTP (col. 2, 
lines 7-10); and 

sending the message envelope to an entity on the network by using HTTP (col. 
2, lines 7-10, lines 27-30). 
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However, Hemphill does not explicitly teach binding the message to an HTTP 
request or response. "Official Notice" is taken that both the concept and advantages of 
binding a message to be sent over a network to an HTTP response or request are well 
known and expected in the art. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to have the messages of the Fuisz formatted for HTTP, as taught 
by Hemphill, and to further bind those HTTP messages to an HTTP request or response 
because HTTP is a well known transmission protocol for transmitting data across 
networks. 

30. Claims 29-31 and 75-77 claim similar limitations to that of claims 11-13 and are 
rejected on the same grounds as claims 11-13. 

31. Claim 40 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Fuisz, in view of Postel (Transmission Control Protocol). 

32. As per claim 40, Fuisz teaches the method of claim 37, but does not explicitly 
teach the sending of response messages. 

In a related art, Postel teaches sending a response message to a sending entity 
on the network (messaging protocol includes positive acknowledgement from the 
receiving entity) (Postel, section 1 .6, page 4, Reliability). 
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Therefore, it would have been obvious to one of ordinary skill in the art at the 

time of the invention to include sending a response to the sending entity, as taught by 
Postel, in the Fuisz invention because it would allow for the system to recover from 
damaged or lost data as taught by Postel (section 1.5, page 4, Reliability). 

33. Claim 66 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Fuisz, in view of Lefebvre, and further in view of Morelli (US 5,838,720). 

34. As per claim 66, Fuisz discloses the claimed modified invention described above 
in claim 65. However, the modified Fuisz invention does not explicitly teach specifying 
error notification in the data structure. 

In a related art, Morelli teaches the data structures specifying whether the entity 
that is intended to process the data structure must respond if it does not understand 
such data structure (determines if the packet is the type that requires a response if 
errors are detected) (Morelli, C9: L1-22). 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to include specifying if a response is requires if the entity did not 
understand the data structure, as taught by Morelli, in the modified Fuisz invention 
because that way a sender of the data structure can flag critical information, forcing 
recipients to respond if there is an error, letting the sender know that the critical 
information was not correctly handled. 
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35. Claim 39 claims similar limitations to that of claim 66 and is rejected on the same 
ground as claim 66. 

Response to Arguments 

36. In the remarks, applicant argued in substance that 

(A) Prior Art does not teach or suggest "headers identify (inherently or 
otherwise) which entity is intended to process the header when that entity receives the 
message envelope over the network". 

As to point (A), Fuisz teaches by taking the advantage of the RFC 822, 
the 822 message is wrapped in an "envelope" called a "data envelope" or a "message 
envelope" (i.e., generating a message envelope) and transferred between servers 
(Fuisz, C4: L65-67); and the content of the message envelope is divided into a header 
and body, wherein the header comprising data structures (e.g,, header fields according 
to RFC 822 such as "From", "Subject", "Sender", "To", "cc", "Bcc", "Received", "Date", 
"Return-Path", "Options", etc., wherein optional-fields may be defined and used on 
Internet security, suggested routing path, previous routing path, time stamps, and 
among other things), and being updated by every Mail Transfer Agent "MTA" and/or 
bounce hub which is intended to identify the type of the message, to obtain any 
necessary forwarding information and to process the message accordingly as the 
message passes through (for example, one or more thru-proxy tags mavbe inserted in 
the header of a message to identify multiple and/or alternate intermediate or final 
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destinations such as a proxy, server or intermediary such that the message is sent to 
the destination in the thru-proxv tag before being sent to the ultimate 
recipient/destination) (Fuisz, C4: L19-31; C4:L65 - C5:L5, and C5: L29-34; RFC 822, 
pages 17-18). 

Hence, prior art does teach "headers identify (Inherently or otherwise) which 
entity is intended to process the header when that entity receives the message 
envelope over the network". 

37. Applicant's arguments as well as request for reconsideration filed on 08/12/2004 
have been fully considered but they are not deemed to be persuasive. 

38. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 . 1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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39. A shortened statutory period for reply to this action is set to expire THREE (3) 
months from the mailing date of this communication. See 37 CFR 1.134. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Quang N. Nguyen whose telephone number is (703) 
305-8190. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
SPE, Rupal Dharia, can be reached at (703) 305-4003. The fax phone number for the 
organization is (703) 872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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